Channel-to-channel (CTC) adapters have been used for many years as a general purpose communication mechanism between computer systems. For example, CTC adapters have been the principle mechanism for connecting multiple S/390 system and zSeries (offered by International Business Machines Corporation of Armonk, N.Y.) hosts together in homogeneous environments. S/390 and zSeries hosts can also be connected to other heterogenous environments, such as IBM's RS/6000 and/or AS/400 systems. The CTC adapter is independent of the end users protocol, and has wide application in areas such as coupling of multiprocessor systems as well as in traditional communications protocol stacks (e.g., TCP/IP, SNA).
The CTC adapter provides a CTC control unit (CU) function within a channel residing in a channel subsystem. The CTC CU function provides control of CTC I/O devices. I/O device types include such components as peripheral cache memories, data storage units such as direct access storage devices (DASD), printers, tape recorders, and the like. From a programming viewpoint, control of a CTC I/O device is accomplished through a logical device (simply “device” hereinafter), each residing in a channel subsystem and associated with a CTC CU function.
When an I/O device is controlled through commands passing from a channel in one channel subsystem to a channel in another channel subsystem via a CTC CU function, the link between the channels is a CTC connection (or channel path) comprising one or more logical paths. When a system first becomes operational, typically at least one logical path is established and one or more CTC connections are initialized, thus allowing I/O commands to control devices. Logical paths and their associated CTC connection may be disrupted after a link failure, which may occur, for example, when a processor is powered off due to its failure or for scheduled maintenance.
After a link failure, a device formerly controlled through the broken CTC connection is non-operational. During this non-operational period, I/O commands to that device are queued, awaiting re-establishment of the formerly established logical path(s). When the error condition is repaired or when maintenance is complete, the affected logical path(s) need to be re-established, thus re-initializing the broken CTC connection.
Because a logical path may be re-established to a channel subsystem that is different from the one it was linked to before the link failure, the integrity and security of data processed by the queued I/O commands need to be assured. Data integrity and security is confirmed through validation of the re-initialized CTC connection. This validation procedure comprises comparing self description data of the device which is to receive the queued I/O commands. The self description data stored before the link failure and is compared to the self description data retrieved after the CTC connection is re-initialized.
Self description data describes a device, and may be constructed from, for instance, identification and configuration data retrieved from a channel. Conventionally, self description data is stored in a configuration data record (CDR). One field of a CDR is a token node element descriptor (TNED). The TNED describing a device identifies the channel subsystem with which the device is associated. If the TNED of a CDR stored before a link failure does not match the TNED of a CDR retrieved after re-initialization of a CTC connection, the CTC connection is considered invalid. With such a finding of invalidity, the re-established logical path for the device is assumed to be connected to a different channel subsystem and thus, to protect data integrity, the device is “boxed” so that any I/O commands destined for the device are rejected.
In the art of CTC connections, further enhancements are needed to minimize the unavailability of devices after link failures.